Document approaches for site builds on top of EESSI#778
Conversation
first attempt at writing the shared fs section
…, after a reboot, the stratum 0 overlay won't mount
…cript. Also, added a full, copyable script combining all the previous components.
Neves-P
left a comment
There was a problem hiding this comment.
Looks really nice! This is my first pass of comments, as of know I only focused on the text. This week I will follow the documentation in practice and review again.
|
|
||
| Another thing to consider is to create a secondary user with `aws iam create-user --user-name <name>` and attach a very limited policy to it (e.g. only read/write/list on buckets, nothing else). Then, create credentials for this user with `aws iam create-access-key --user-name <name>` and provide those credentials to the EESSI build bot and Stratum 0 machines. That way, if that token is compromized, the impact is minimized (e.g. the token can at least not be used to create new IAM idententies, etc). | ||
|
|
||
| ## Setting up the EESSI build bot |
There was a problem hiding this comment.
I'd consider separating this into a new page. The build bot is somewhat self contained and the page is quite long already.
|
|
||
| Another thing to consider is to create a secondary user with `aws iam create-user --user-name <name>` and attach a very limited policy to it (e.g. only read/write/list on buckets, nothing else). Then, create credentials for this user with `aws iam create-access-key --user-name <name>` and provide those credentials to the EESSI build bot and Stratum 0 machines. That way, if that token is compromised, the impact is minimized (e.g. the token can at least not be used to create new IAM idententies, etc). | ||
|
|
||
| ## Setting up the EESSI build bot |
There was a problem hiding this comment.
I realize these docs lack one crucial thing: setting up a site_config_script that sets EESSI_SITE_INSTALL_FORCE and EESSI_SITE_SOFTWARE_PATH_PREFIX
There was a problem hiding this comment.
I.e. at SURF, our site_config_script looks like this:
# To build on top of EESSI, we need to software.eessi.io repository to be mounted next to our own repository
# The bot/build.sh script does this when the EESSI_SITE_INSTALL_FORCE environment variable is set
# Other build scripts will also respect this variable where needed in order to make sure that 'building on top'
# of EESSI is possible
export EESSI_SITE_INSTALL_FORCE=1
echo "Value of EESSI_SITE_INSTALL_FORCE: $EESSI_SITE_INSTALL_FORCE"
# We also need to set a prefix that our installations should end up in
# The build scripts should take this prefix, and construct the final EESSI_SITE_SOFTWARE_PATH out of it
# that the EESSI-extend module expects
export EESSI_SITE_SOFTWARE_PATH_PREFIX=/cvmfs/software.surf.nl/versions/2025.06/
echo "Value of EESSI_SITE_SOFTWARE_PATH_PREFIX: $EESSI_SITE_SOFTWARE_PATH_PREFIX"
One thing to figure out might be how to avoid hard-coding the version in here :)
There was a problem hiding this comment.
Scratch that, this should not be needed anymore... I think we do this differently now... We automatically set these here https://github.com/EESSI/software-layer-scripts/blob/ca929cd7ef32a9fcd79fafd4e0d5c362a1fff452/bot/build.sh#L156 . That happens if the repo_name in the repos config file is unequal to software.eessi.io or dev.eess.io essentially.
No description provided.